Public key cryptography utilizes a public key and a private key that are mathematically related. The relationship is such that the public key can readily be computed from the private key but computation of the private key from the public key is considered infeasible. The private key is thus maintained secret. The keys are used in a variety of well known protocols to hide or sign messages.
As a cryptographic value, a public key or its representation generally is not easily manageable by a user. Generally speaking, cryptographic algorithms involve values that are random or indistinguishable from random characters within a certain space. People generally have difficulty managing a long string of characters that resembles a random collection of letters and digits. To provide adequate security, the size of such a space is often chosen so that exhaustive search by computers of current technology becomes infeasible. A space of 280 is considered out of reach today. Representing a cryptographic value in such a space generally takes at least 80 bits, or ten bytes. A value of ten bytes corresponds to twenty hexadecimal digits. Some cryptographic values, such as elliptic curve public keys and hash values, must generally be twice as long as this to have an equal security level. The minimal security level would involve a representation of 40 hexadecimal digits. As computation power or computation techniques advance, longer representations will become desirable or necessary. Other cryptographic values, such as DSA and RSA keys, have even longer representations, with 256 hexadecimal digits in order to maintain the same security level.
Random values of such sizes, even just 20 hexadecimal digits long, are quite difficult for users to manage without error. In particular, users may have difficulty                1. recalling such random values without assistance,        2. recognizing such random values even if seen before,        3. communicating such values by voice to other users, or        4. transcribing such values via print or display.        
Because of these difficulties, user interfaces to cryptographic protocols seldom give users access to the cryptographic values. This may be because it is generally believed that such access would be useless. Occasionally, cryptographic values are made optionally accessible to users. The most common cryptographic value that users are likely to encounter is a public key. Many protocols optionally display a representation of a public key in a certificate to the user.
For example, when an SSL or TLS client in a web browser receives a server certificate which is not signed by a trusted certification authority (“CA”), the SSL or TSL client commonly displays a warning to the user. The warning message typically notifies the user that the certificate cannot be trusted, displays the name of the purported owner and issuer of the certificate. Often an option is given to the user to either not trust the certificate, trust the certificate once, or to always trust it. Some clients also display the public key in hexadecimal or Base64 form to the user. Users generally cannot make use of the displayed public key, because they have nothing to corroborate against. Even if the user did have some authentic source to verify the public key against, a hexadecimal or Base64 representation would make the verification a nuisance.
These warning messages present a danger to users. Suppose a user tries to revisit a familiar, secure but uncertified site, but accidentally misspells the web address. An attacker could create a web-site at the mistaken address. The attacker could create a web page that looks identical to the correct web-site. The attacker can also create a server certificate for the web-site. The attacker may not be able to get the server certificate certified by a trusted CA, because the trusted CA may do due diligence against such attacks before issuing server certificates. However, the attacker can issue a certificate to itself.
When a browser client encounters such a certificate, it will recognize that the certificate is not certified by a trusted CA and accordingly warn the user. Some users may ignore the warning message and connect to the site regardless. Other users may reject the web-site, without regard to the warning. A third class of users, perhaps the majority, may glance at the name of the certificate presented in the warning message and choose to accept the certificate once (for one session).
This third class of users would inspect the name. Because the certificate has been issued by the attacker, the attacker can choose a valid name, one for the correct site. If the browser matches the name, against the URL, then the attacker can use the matched URL. The false URL is very close to the true URL, however, so the user may not notice the difference. (Some browsers might not re-display a correctly matched URL in the warning message, since it is already displayed in the address line of the browser.)
Therefore it is likely that this third class of users will accept the certificate, at least for one session. This is made more likely by the fact that many legitimate web-sites cannot afford to purchase server certificates from trusted CAs, but still want encryption, so instead just issue their own certificates. Many users have been accustomed to such sites, and are more likely to accept certificates.
The negative consequence of accepting the attacker's certificate is that the user may think he or she is communicating with the true web-site. The user may obtain false information from the false web-site. The user may also enter information into the false web-site. In particular, the user may enter a password. The attacker may obtain the password, and use it to impersonate the user at the true web-site. If the true web-site is an on-line banking site, the attacker may be able to withdraw funds from the user's bank account.
It is therefore desirable to communicate cryptographic values to human recipients in a text representation, which tends to have a less random form. Solutions have been proposed in the context of one-time passwords that are hashes of salted conventional passwords. In one system, a stream of 64 bits is divided into six segments of 11 bits with one of the segments padded to 11 bits. Each segment is then rendered as a word taken from a dictionary of 2048 words. The words chosen have four or fewer letters, with the purpose to make them easier to type, so that the number of key strokes is limited. The aim is to keep the error rate lower than for hexadecimal or Base64 data, because the words chosen are valid English words.
A number of security deficiencies, however, exist in using lists of English words. Audio recordings of speech can be re-spliced to form word lists. Thus if speech is used for authentication then alternative representations may be advantageous. At a textual level, word lists may not offer as much efficiency or may not fit well enough with existing text formats, such as electronic mail addresses.
It is an object of the present invention to mitigate or obviate at least one of the above mentioned disadvantages.